In many computing systems, low-level instruction code, or firmware, is used as an intermediary between the hardware components of the computing system and high-level software executing on the computing system, such as an operating system. The firmware provides a set of software routines that allow high-level software to interact with the hardware components of the computing system using standard calls. In some computer systems, the Basic Input/Output System (“BIOS”) has been a de facto standard defining a firmware interface. The BIOS, however, is now being replaced by the more capable Extensible Firmware Interface (“EFI”)-compatible firmware. EFI-compatible firmware may be configured according to a specification released by the Unified EFI (“UEFI”) Forum (the “UEFI Specification”). Such a firmware may be referred to herein as a UEFI specification-compliant firmware or a UEFI firmware in short.
During the transition from the legacy/traditional BIOS firmware to UEFI firmware, a hardware device may include both a legacy/traditional BIOS option read-only memory (“ROM”) and a UEFI option ROM. As known to those skilled in the art, the option ROM of a hardware device contains program code executable by the system, such as a driver that is used to connect and utilize the hardware device to the system once the option ROM is loaded. One of the reasons that a legacy BIOS option ROM may still exist on a hardware device may be that the device may need to boot a traditional operating system (“OS”) in a UEFI environment, in which case, all the hardware devices need to include a traditional option ROM. Another reason is that a legacy driver provided in a legacy option ROM may be preferred over a UEFI driver (also called a UEFI native driver) because the legacy driver may have been proven to be more reliable than the UEFI native driver.
Current UEFI firmware does not include a mechanism to specify which of the drivers on the option ROM(s) may be connected to or used to manage a hardware device. Similarly, there may be scenarios where multiple alternative drivers may be available for managing the same hardware device. For example, in an INTEL RAID controller manufactured by INTEL CORPORATION, there may be an INTEL RAID driver provided by INTEL CORPORATION and also an LSI RAID driver provided by LSI CORPORATION. Some users may prefer the LSI RAID driver over the INTEL RAID driver when managing the RAID controller, while others may prefer the INTEL RAID driver over the LSI RAID driver. Thus, it would be convenient to enable the control of driver selection based on a user preference in a firmware environment.
It is with respect to these and other considerations that the disclosure made herein is presented.